There are three scenarios during the process of User Equipment (abbreviated as UE) authentication and the process of achieving Single Sign-on (abbreviated as SSO) of a uniform IP Multimedia Subsystem (abbreviated as IMS), wherein the three scenarios are as follows.
1. The case that there is a Universal Integrated Circuit Card (abbreviated as UICC) in the IMS UE and the network operators have already deployed a General Bootstrapping Architecture (abbreviated as GBA): at this moment the single sign-on and the interconnection with other SSO mechanism can be achieved by using the combination of the GBA and Liberty Alliance/Open Identity Identification (OpenID). Under this scenario, in order to achieve the SSO, the operators will deploy a large amount of GBAs, and at the same time embed a UICC in each IMS UE and use the information in the GBAs and the UICCs to complete the SSO function of an IMS terminal accessing an application server.
2. The case that there is a UICC in the IMS UE but the operators cannot deploy the GBA: in this case the UE terminal user needs to be authenticated and when the SSO function of this IMS terminal accessing the AS application server is achieved, the combined solution of authentication and Key Agreement (abbreviated as AKA)/OpenID is often used, which is in particular as follows.
The IMS UE sends an authentication request to the Application Server (abbreviated as AS, also referred to as RP), wherein the request comprises an OpenID identifier; the RP uses this OpenID identifier to find the final Uniform/Universal Resources Locater (abbreviated as URL) of an OpenID Provider (abbreviated as OP) and redirects the user authentication request to this URL; the OP acquires an AKA authentication vector and the user terminal information contents based on IP Multimedia Private Identity (abbreviated as IMPI) from a Home Subscriber Server (abbreviated as HSS); the OP uses an AKA authentication method to send an authentication challenge to the UE to make the UE authenticate this network; the UE sends a response according to the challenge to the OP and the authentication of the UE is finished in the OP. The OP sends an assertion declaring that the OpenID identifier belongs to the marker information of this terminal, wherein the assertion is marked up by the OP using a shared key (the key can be a shared key between the OP and the RP and can also be the key of the OP itself) between the OP and the RP; this assertion is redirected to the RP; if the shared key between the OP and the RP is used, then the RP directly verifies the signature information and informs the UE of the verification result; and if the key of the OP itself is used to perform encryption, then the RP transfers the copy of this assertion to the OP to verify the copy, the OP informs the RP of the verification result and finally the RP informs the UE of the verification result.
By this architecture, the network operators can provide the service function of identity verification for the users accessing a WEB server as OpenID providers. For an application storing an ISIM (an identity identification in the IMS), the users can provide cross-IMS and web server and the like to achieve the SSO function thereto. The users are allowed to control their public identity identifiers on the WEB. The information security of the users themselves can be improved by the users accessing the WEB applications controlled by those reliable network operators.
3. The case that there is no UICC in the IMS UE and the operators neither deploy the GBA: with the increasing of non-UICC terminals accessing IMS network, the occurring probability of this case is larger and larger, and in the case that the GBA and the non-UICC are not deployed, the users also need to access the IMS network and use IMS relevant application services. In this case, the non-UICC-based IMS-SSO authentication becomes very necessary. However, how to perform the SSO function under such scenario is still not proposed in the related art.
In summary, in the related art, only those terminals with UICCs can achieve the SSO function and then access various application services in the IMS network, and in most cases it is required that the network operators deploy a large amount of GBAs, which will increase the investment cost of the operators; while those terminals without UICCs will not be able to use the existing architecture solutions to achieve the SSO function to the relevant application services in the IMS network.